FIG. 1 depicts a prior art architecture for processing alarms from enterprise telecommunications components, such as Private Branch Exchanges and media servers. The alarm processing system comprises the enterprise telecommunications component 100 and an alarm handler 104 both of which are in communication with an enterprise modem 108 and an enterprise Local Area Network or LAN 112. Through an enterprise gateway 116, the enterprise telecommunication component 100 and alarm handler 104 are in communication with a Wide Area Network 120, such as the Internet, and to a service provider's gateway 124. Through the enterprise modem 108, the telecommunications component 100 and alarm handler 104 are in communication with the Public Switched Telephone Network or PSTN 128 and to a service provider's modem 132 and service router 136. The service provider is, for example, a manufacturer that monitors products in the field or an entity, such as Norstan™, hired by the operator of the enterprise network to monitor and process alarms in the enterprise network. Communications received either through the service gateway 124 and the service router 136 are directed to a firewall 140. From the firewall 140, the communications are directed via a LAN 144 of the service provider to a service provider alarm fault manager 148.
The alarm handler 104 receives alarms and/or error messages from the enterprise telecommunication component 100, reads the alarm and/or error messages, optionally adds additional information depending on the application, formats, and forwards the alarms to the alarm fault manager 148 either via a serial interface (not shown) and the enterprise modem 108, typically in ASCII form, or via an ethernet interface (not shown), typically in a collection of packets constructed as defined in the TCP/IP suite of protocols. The alarm handler 104 can add to the alarm and/or error message a standardized header to aid in parsing the alarms or route the alarms to specific alarm reception centers that anticipate the form of the alarm.
The alarm fault manager 148 accepts and processes messages received from the alarm handler, logs the messages and passes the processed information to the database 152. The manager 148 comprises an encoder 156, an IP alarm manager 160, and a formatting agent 164. The encoder 156 passes processed Simple Network Management Protocol or SNMP messages from the alarm handler 104 to the formatting agent 164 and receives the messages back in ASCII form. An example of a suitable encoder is the G2™ encoder manufactured by Gensym™. The formatting agent 164 also formats the messages into a specified format for further processing. The formatting agent 164 further includes various parsers to parse the received messages and an encoder application (not shown) to encode the alarm information into the fields in the specified format. The encoder 156 correlates and filters the messages, and the IP alarm manager 160 provides an application processing interface with the database 152 for the processed, correlated and filtered messages.
The service provider typically monitors alarms generated by various types of enterprise telecommunication components and alarm handlers. For example, the telecommunication components can be PBX's made by manufacturers including Avaya Inc.™, Northern Telecom™, and Siemens™. The alarm handler can also be made by different manufacturers, such as the Access Security Gateway™ manufactured by Ion Network™ and Site Event Buffer™ manufactured by Teltronics™. The ability to process the arbitrary streams from various manufacturers using differing alarm syntaxes, symbols, and formats is limited. The alarm messages are vendor specific and not standardized. In addition, an alarm stream of one syntax and format may be nested deep within another alarm stream of a different syntax and format without any header information to help differentiate among the differing alarm streams. To make matters worse, some alarm formats are proprietary and must be reverse engineered. The parsers currently in the formatting agent 164 employ rather simplistic parsing techniques that are often unable to parse accurately the alarm streams, thereby diminishing the ability of the service provider to accurately and effectively monitor the alarms received from the enterprise network.